Description

MMDS BottomSheet now handles pure-black elevated surface styling internally. This PR removes the redundant useElevatedSurface() shim and twClassName prop from the two remaining accounts-engineer callsites scoped in TMCU-1048.

Changes:

• ConfirmTurnOnBackupAndSyncModal — removed useElevatedSurface import/usage and twClassName on BottomSheet
• LearnMoreBottomSheet — removed useElevatedSurface import/usage and twClassName on BottomSheet

Changelog

CHANGELOG entry: null

Related issues

Fixes: TMCU-1048

Manual testing steps

Feature: Pure black elevated surface on MMDS BottomSheet

  Scenario: Backup and sync confirm sheet renders with correct surface
    Given the app is in dark mode with pure black preview enabled
    When the user opens the backup and sync confirmation bottom sheet
    Then the bottom sheet surface should use the elevated background (not collapse into pure black)

  Scenario: Multichain intro learn-more sheet renders with correct surface
    Given the app is in dark mode with pure black preview enabled
    When the user opens the multichain accounts learn-more bottom sheet
    Then the bottom sheet surface should use the elevated background (not collapse into pure black)

N/A for automated cloud-agent environment — visual QA requires device/simulator with pure black preview enabled.

Screenshots/Recordings

N/A — visual surface change only; requires device QA with pure black preview enabled per acceptance criteria.

Before

N/A

After

Backup and Sync BottomSheet background color still works as expected

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.